Multi-media jitter removal in an asynchronous digital home network

ABSTRACT

A method and an apparatus using a system level clocking scheme to remove jitter from multi-media packets distributed over an asynchronous network, in particular an asynchronous network. The present invention overcomes the problems associated with jitter introduced in an asynchronous network by using various time stamps to synchronize a client device clock to a headend clock and to control the data flow in the client device to match the rate that the data is received by a broadband receiver coupled to the headend. A first time stamp is prepended to the transport packets when the packets are received from the headend. A second time stamp is placed in the data frame when the data frame is placed on the network. A third time stamp is placed in the data frame when the data frame is received from the network. The second and third time stamps are used for synchronizing the client clock to the server clock, which is in turn frequency locked to the headend clock. The first time stamp is used for data flow control wherein the client controls the data now to correspond to the rate the data is received at the server.

[0001] The present invention relates to an asynchronous communicationsnetwork, and in particular, to an asynchronous multi-media digital homenetwork having a system level clocking scheme to remove jitter frommulti-media data packets.

[0002] Recent advances in digital communications technology haveincreased the viability of digital home networks (“DHN”), which canallow various devices in a home to communicate with each other. Inparticular, the growing availability of broadband access has made itdesirable to be able to tie in various devices in a home to a singlegateway device that is coupled to the broadband access for centralizedaccess and distribution of multi-media information. In such a digitalhome network, the gateway device accesses and buffers multi-mediacontent and distributes the content over the network as requested byvarious client devices coupled to the network.

[0003] Ethernet is a common option for implementing a LAN. Ethernet isan asynchronous collision detect network. HPNA is also an asynchronouscollision detect network and some power line based networks are oftenasynchronous collision detect networks. However, difficulties may arisewhen such networks are used to distribute multi-media content.

[0004]FIG. 1 is a system diagram illustrating a multimedia network.System 100 comprises a plurality of devices 108-113 coupled to mediaserver 103 via one of a plurality of communications networks 105-107. Insystem 100, media server 103 receives multi-media content via satellitedish 102, buffers the content, and distributes the content as requestedfrom the various devices coupled to the network. Media server 103 mayalso be coupled to receive multi-media content via any one of pluralityof known digital media access methods, including, cable, and DSL. Thetransfer of data over the selected network is generally achieved byusing large buffers or by allowing a client device to throttle data.

[0005] In this regard, there are a number of problems associated withtaking a live broadcast and distributing it on an asynchronous digitalhome network. In a live broadcast signal, the data is pushed to theclient device, and the client device does not have any control over theincoming data stream. In order to ensure that the networked clientdevice can decode and display all of the audio and video data deliveredto it at the correct frame rate, and without repeated or dropped frames,it is in general required that the networked client device be clocksynchronized to the network gateway device. The most widely acceptedmethod for clock synchronization in a broadcast AN network relies ondelivering counter samples taken at the broadcast site to the receiverwith a fixed delay from the time of broadcast till the time of receipt.The counter at the broadcast site is incremented by the broadcast site'sreference clock. At the instant those clock samples arrive in thereceiver, a counter clocked by a voltage controlled oscillator (VCXO) issampled. The value of the counter and the time stamp received from thebroadcast site are compared and if the difference between the samples ofthe local counter and the clock samples taken at the broadcast sitevaries over time, the voltage applied to the local VCXO is adjusted totry to frequency lock the local clock to the broadcast site's referenceclock.

[0006] On an asynchronous collision detect network, such as an Ethernetnetwork, the delay from the time a packet is constructed and placed in atransmit buffer until the time the packet is received by a networkconnected device is not always constant. In such networks, multipledevices colliding on a network can cause variable packet andunpredictable delays in the reception of a packet. In this environmentit is not possible to use the method described above to frequency lockthe clock at the networked receiver to a clock at the networkedtransmitter due to the variable and unpredictable delays. Using such amethod to attempt to lock the receiver clock to the transmitter clockmay produce significant jitter in the receiver clock. Depending upon themagnitude of the jitter in the receiver's clock, it may not be possibleto produce an NTSC compliant color burst for video display. In addition,this jitter will at a minimum require the audio and video compresseddata buffers to be larger than necessary and at worst cause the buffersto underflow or overflow. The side effects would include video freezing,possible audio chirps and the display colors changing dynamically due tothe variations in the color burst.

[0007] Some networks, such as 1394 networks, provide isochronouscapability that can eliminate this problem. Additionally, variousmethods, such as SRTS, have also been developed for ATM networks toaddress these timing issues. The SRTS method assumes that thetransmitting device and the receiving device both have access to anetwork clock for the synchronization. However, such methods may not becompletely suitable for correcting jitter in an asynchronous collisiondetect network, such as an Ethernet network. Therefore, what is desiredis a system and a method for synchronizing the clocks and controllingthe data flow in an asynchronous network, and in particular, in anasynchronous collision detect network to overcome the above-notedproblems.

[0008] The present invention overcomes the jitter problems discussedabove, and in particular, provides a system and a method fordistributing multi-media content over an asynchronous network. Morespecifically, the present invention uses time stamps to minimize andreduce the jitter effects caused by software processing and collisionson an asynchronous home network. Time stamps are used to performsynchronization of the clock in the client device to the server clockand also to control data flow in the client device.

[0009] One set of time stamps is added for flow control. When a packetarrives from a broadband network, a sample of a local counter in theserver is latched into a register. The server attaches the sampledcounter value to the received transport packets. The local counter isclocked with a system clock that has been frequency locked to the systemclock at the headend. Once a packet is time stamped, the server mayplace the packet in a transmit buffer. This time stamp indicates themoment at which the data was received from the broadband connection andplaced into a buffer, and as such, can be used by the client device toremove the data from a receive buffer at the exact same rate as itentered the buffer.

[0010] Another set of time stamps is used for synchronizing the clientdevice clock with the head end clock. At the moment a frame of data isbeing placed onto the network, a local counter running on the systemclock is sampled. A time stamp based on the sampled clock is placed inthe data frame in real-time at the physical layer of the network so thatthere is a fixed and constant amount of time from the sampling of thelocal counter and the sampled count value being placed onto the network.If a collision occurs, the time stamp is updated when the data isretransmitted. At the moment the new data frame is received in thephysical layer of a client device, a sample of a local counter runningon the client's local clock is latched into a register. This“receive-time” time stamp is then attached to the received frame of dataand passed onto successive layers of the client's network protocolhardware and software. After the client data is passed through thecommunication protocols, the data is ready to be used by the client.

[0011] The client device uses the time stamps attached at the physicallayer of the server's network interface, along with the time stamps thatwere attached when the data was received by the client device to lockthe client's local system clock to the server's local system clock.Since the server's local system clock is frequency locked to the headendsystem clock, the client system clock will also be frequency locked tothe headend system clock. Frequent clock samples from the server willallow the client's system clock to very closely track the server'ssystem clock.

[0012] The time stamps attached to the data when the data arrived at theserver from the broadband network may then be used to determine theexact time when each data packet should be extracted from the client'sbuffer and passed on to the audio/video subsystems in the client. Inthis way the packet arrival timing at the server is exactly matched atthe input to the A/V subsystem in the client device.

[0013] The invention is described with reference to the drawings,wherein:

[0014]FIG. 1 shows an asynchronous multi-media network including a mediaserver coupled to a plurality of client devices;

[0015]FIG. 2 is a block diagram illustrating the elements of anasynchronous multi-media network including time stamps placed into thedata at various points of the network according to the presentinvention;

[0016]FIG. 3 shows format of the data frame including the time stampsutilized in the asynchronous multi-media network according to thepresent invention;

[0017]FIG. 4 is a block diagram illustrating the element of a broadbandreceiver adapted to receive satellite signals;

[0018]FIG. 5 is a block diagram illustrating the elements of the PCI DBStuner board illustrated in FIG. 4;

[0019]FIG. 6 is a block diagram illustrating the elements of the clientdevice illustrated in FIG. 2;

[0020]FIG. 7 is a block diagram illustrating the elements of thetransport formatter board illustrated in FIG. 6;

[0021]FIG. 8 is a block diagram illustrating the elements of the clientvideo decoder illustrated in FIG. 6;

[0022]FIG. 9 is a block diagram illustrating the time stamping boardused in the asynchronous multi-media network according to the presentinvention;

[0023]FIG. 10 is a block diagram illustrating the time stamp controllerin the time stamping board shown in FIG. 9;

[0024]FIG. 11 is a block diagram illustrating the receiver unit in thetime stamp controller shown in FIG. 10; and

[0025]FIG. 12 is a block diagram illustrating the transmitting unit inthe time stamp controller shown in FIG. 10.

[0026]FIG. 2 illustrates a digital home network utilizing the timestamps according to the present invention. The broadband input signal isprovided by a headend (not shown) and received by broadbandreceiver/multi-media server 202. Server 202 may be configured to receivethe input from one of a plurality of broadband sources, such as,satellite, cable or DSL, as indicated by input Sys 1, Sys 2 . . . Sys n.This input signal may be in the form of transport packets, which includeSystem Clock Recovery (SCRs) information used by receiver 202 tofrequency lock its local system clock to the head end system clock. TheSCRs are used to mange buffer levels and to derive video timing andcolor burst signals in an integrated receiver decoder (IRD). It isimportant to note that the SCR information and packet timingrelationships must be maintained throughout system 200, from entry intothe network to the point of final presentation, in order for system 200to operate properly.

[0027] Data received by server 202 from the broadband network istransport packetized. Some of these transport packets will carry samplesfrom a counter at the head end that is clocked by the head end's systemclock. Using these counter samples and the arrival time of the transportpackets that carry these samples, server 202 is able to frequency lockits own local system clock to the head end system clock.

[0028] In accordance with the present invention, in order to ensure thatthe exact arrival time of packets at the client device may bereproduced, each packet arriving from the broadband network is stampedwith a time stamp, T1, when server 202 receives the packet. Time stampT1 is a sample of a local counter that is clocked with a local systemclock of server 202. Time stamp T1 and the packet are stored together inbuffer 205 prior to being broadcast together over the DHN.

[0029] At some later point in time, a group of transport packets, alongwith header information, is assembled to form a data frame fortransmission on the network DHN. The moment the data frame starts to beplaced onto the network, local counter in server 202, running on thelocal system clock, is sampled to generate a counter sample time stampT2. Time stamp T2 is prepended onto the beginning of the outgoing dataframe such that the time from sampling the counter value to the time thecounter value enters the network is fixed and constant. It is importantthat this time is fixed and constant, and for this reason the countersampling and time stamp placement is performed in the physical layerhardware of the network interface. Since the propagation delay fromserver 202 to client device 204 over the network is fixed and constant,the overall propagation delay from sampling T2 until the packetcontaining time stamp T2 arrives at client device 204 is also fixed andconstant. Additionally, in a network where the symbol times may change,the present invention is able to provide synchronization as long as thepropagation times remain constant.

[0030] At the moment the data frame arrives at client device 204, alocal counter of client device 204, running on the client system clock,is sampled to generate a time stamp T3. This counter value is comparedto time stamp T2 in the arriving data frame to ensure that thedifference between the client counter and the server counter is notchanging. If this difference is changing over time, the client devicewill modify the voltage on its local VCXO to move its local system clockinto frequency lock with the system clock of server 202. Thus, timestamps T2 and T3 are used to frequency lock the system clocks of server202 and client device 204 together. Time stamps T2 and T3 may bediscarded after they are used in client device 204 for synchronization.At this point, data frames that encapsulate transport packets and theirassociated time stamps T1 may be stored in buffer 203 in client device204.

[0031] The next step is to remove data from the buffer of client device204 at a rate that exactly matches the rate at which the packets arrivedat the input of server 202. When client device 204 has accumulatedenough data in a receive buffer to absorb a reasonable amount of networkjitter client device 204 starts extracting data from the receive buffer,and making that data available to the decoders within client device 204.A local counter, which is based on the client clock is initialized withthe count value stored with the first transport packet to be extractedfrom memory. The counter is clocked with the client's system clock,which is locked to the server clock, so the subsequent packets may beextracted from memory when their stored time stamp value matches thecounter value. In this manner, the rate of removal from the receivebuffer of client device 204 matches the rate at which the data wasreceived at server 202. The format of the data packet and placement ofthe time stamps T1, T2 and T3 within the data frame are shown in FIG. 3,wherein the time stamps T1 are generated as the packetized data isreceived and time stamps T2 are placed into the data frames as theframes are placed on the network DHN and time stamp T3 is generated whenthe data frame is received from the network DHN.

[0032] The format of the data packets and the placement of the timesstamps into the data frames in an Ethernet environment are furtherdescribed below. The Ethernet packets in the present embodiment use theUDP/IP protocols, but it is to be understood that other suitableprotocols, such as TCP, or “raw” Ethernet may be used to implement thetime stamping features of the present invention. In accordance with thepresent invention, the IP header utilizes an IP option identifying thedata frames that need to have a time stamp placed therein. The timestamps are placed in the data frames following the UDP header. There isa unique location in the extended UDP header for the outgoing andincoming packets.

[0033] The clock synchronization time stamps T2 and T3 are placed afterthe UDP header. Time stamp T2 is a 32-bit time stamp and is applied whenthe IP packet has an option 25 set. The time stamp placed into the dataframe at the physical network layer. Although the present embodimentutilizes option 25 to indicate the presence of time stamps in the frame,it is to be understood that other suitable method for indicating timestamps, such as designating specific IP address and port number may beutilized.

[0034] Time stamp T3 is also a 32-bit incoming time stamp and is appliedwhen an IP packet with option 25 is detected. This time stamp is alsoplaced into the data frame at the physical network layer. Table 1 belowshows the placement of time stamps T2 and T3 in the UDP data frame.TABLE 1 UDP data frame 0   15 16       31 16-bit source port number16-bit destination port number 16-bit UDP length 16-bit UDP checksum32-bit time stamp T2 32-bit time stamp T3 Data (if any)

[0035] Using the time stamps at the physical layer, the presentinvention can develop an algorithm to synchronize the two independentnodes, in this case server 202 and client device 204.

[0036] The data flow control time stamps T1 are placed into the datastream when the data is received from a broadband network. Time stampsT1 are generated using a local counter in server 202 that is incrementedby a clock that is frequency locked to the system clock at the headend.By placing a time stamp T1 on each transport packet as the packetarrives at server 202, client device 204 can reproduce the same bit rateas the rate received at server 202. Data flow control time stamps T1 areplaced in the UDP payload. Table 2 shows the data format used in theexemplary embodiment of the present invention. This data is placed inthe data portion of the UDP data frame shown in table 1. TABLE 2 Dataincluding transport packets and time stamps 0   15   16   31 TransportPacket Marker 16-bit MSBs of time stamp T1 (0) 16-bit LSBs of time stampT1 (0) Transport Packet 0 Transport Packet Marker 16-bit MSBs of timestamp T1 (1) 16-bit LSBs of time stamp T1 (1) Transport Packet 1 . . .Transport Packet Marker 16-bit MSBs of time stamp T1 (n) 16-bit LSBs oftime stamp T1 (n) Transport Packet n

[0037] Once the data frame has been time stamped, the UDP checksum ischecked. If the checksum is not zero, the old checksum is replaced witha newly created checksum. After resolving the UDP checksum, a new CRC iscalculated and replaces the old CRC value in the MAC layer. If at anypoint of the packet interrogation it is determined that the data frameis not a valid time stamp frame, the frame is passed through with noalterations to the data.

[0038] The time stamp value is generated from an external system clock.The external clock drives a 32-bit counter. A snapshot of the counter istaken when a data frame is placed onto the network. On an incomingpacket, a snapshot of a counter in the client device is taken. If it isa valid time stamped packet, the snapshot of the counter is placed intothe payload portion of the data frame. The 32-bit counter is a freerunning rollover counter synchronous to the external system clock.

[0039] The following describes the search sequence to determine whethera particular data frame needs a time stamp, and if so, where the timestamp data is placed. The first test is to validate the MAC frame.Validating the MAC frame requires the CRC to be calculated and compared.If the CRC test fails, the frame is allowed to pass through without anymodifications to ensure that a valid CRC is not added to a data framethat was received with an invalid CRC. If the CRC test is passed, asecond test is conducted to find an Internet Protocol (IP) in the MACframe. Twenty octets into the MAC frame, from the 802.3 specificationsection 3.2.6, Length/Type, is the Length/Type field. From ITEF RFC 1700EtherTypes table, an Internet IP (Ipv4) is 0x800 (Hexadecimal). If thevalue is not 0x800, the packet is passed through. If the Length/Type is0x800, another test is conducted to determine the size of the IP headerand whether it contains an UDP packet. The contents of a MAC frame arespecified in IEEE 802.3, section 3.1.1.

[0040] If the MAC frame contains an IP packet, the next test determinesthe size and the option settings. First, in order to determine the size,the second nibble of the IP packet, which is the Header Length, isexamined. The Header Length is the number of 32-bit words that make upthe IP header. Without options, the IP header is normally 20 bytes, sothe Header Length is 5. The IP Header options have a 20 decimal offsetfrom the start of the IP Header.

[0041] The steps to determine whether the packet is a valid time stamppacket is now described. If any of the steps fail, the packet is passedthrough without any modifications. First, the header length field isexamined to determine whether it is greater than 5. If so, the 1^(st) IPoption located 20 bytes from the beginning of the IP Header is checkedagainst 0x99040000. The format of the option is shown in Table 3 below:TABLE 3 IP Option 25 Class Parm Copy (2 Number Length (16 (1 bit) bits)(5 bits) (8 bits) bits) 1 0 25 4 0

[0042] Table 4 shows an IP header with IP option 25 included. TABLE 4 IPHeader with IP Option 25 15 16 0 4-bit 8-bit type 4-bit header ofservice 31 version length (TOS) 16-bit total length (in bytes) 16-bit3-bit 13-bit fragment offset identification flag 8-bit time to 8-bit16-bit header checksum live (TTL) protocol 32-bit source IP address32-bit destination IP address 32-bit option 25 data

[0043] If the IP options include the designated time stamping optiondescribed above, the present system places a time stamp into the dataframe. The time stamps are placed in the UDP payload portion thatfollows the IP header, and in particular, at the beginning of thepayload portion. The UDP header is 8 bytes long. The first 32 bit wordof the UDP payload is reserved for time stamp T2, the outgoing timestamp, and the second 32 bit word of the UDP payload is reserved for T3,the incoming time stamp. Table 1 shows the general format of the UDPdata frame while table 2 illustrates the specific format chosen for theexemplary embodiment of the present invention.

[0044] A significant aspect of the present invention is that the timestamps and the CRC are generated and placed into the data frames at thephysical layer. As such, the time stamps and CRC are placed into thedata frames as the data frames are being placed onto the network or arereceived from the network. This allows the time stamps to accuratelyreflect the time the data enters the network and the time the data isreceived from the network.

[0045] The elements of a system for implementing the time stampingdescribed above is now described in further detail with respect to a DBSreceiver. However, it is to be understood that similar time stamping maybe performed for multi-media data received on other types of broadbandnetworks, such as DSL or cable.

[0046] As shown in FIG. 4, server 202 consists of three functionalblocks connected by a bus. The satellite signal is received by server202 through PCI DBS tuner 402. Host controller 406 reads the transportpackets from the satellite signal out of PCI DBS tuner 402 via PCI businterface 405. Host controller 406 then processes the data and sends theprocessed data out to time stamp board 404 via well-known protocols,including UDP. Also, PCI DBS tuner 402 and time stamp board 404 have acommon clock between them. The clock is generated on PCI DBS tuner 402,and used as the time reference for time stamp board 404.

[0047] In operation, host controller 406 reads the transport packets outof the FIFO memory of PCI DBS tuner 402. The packets are then processedaccording to the network protocol software and the network frames arethen written into the Ethernet MAC of time stamp board 404. The MACwaits for the Ethernet Network to become available, and then sends thedata through a time stamp controller to an Ethernet PHY. When a videonetwork packet is detected by the time stamp controller, a time stamp isadded to that packet. The time stamp T2 is a sample of a counter in thetime stamp controller that is clocked by a recovered clock source. Inserver 202, the clock source for the time stamp controller is a VCXO inPCI DBS tuner 402.

[0048]FIG. 5 shows a block diagram of PCI DBS tuner 402. PCI DBS tuner402 performs three major functions. First, PCI DBS tuner 402 ensuresthat the correct satellite transponder is selected, tuned, anddemodulated. This is accomplished by satellite tuner 502 and demodulator504. These devices perform the well-known conversion of a satellitesignal into a digital transport stream.

[0049] Second, PCI DBS tuner 402 filters the packets of the transportstream. Tuner controller 506 contains logic to filter out only thetransport packets requested by host controller 406. The transportpackets are then stored in FIFO buffer 512. Host controller 506 can thenread the packets out of FIFO buffer 512 via PCI bus interface 405. Inorder to facilitate the PCI bus interface, a PCI bridge chip 508 isused.

[0050] Third, PCI DBS tuner 402 performs clock recovery. Tunercontroller 506 executes software instructions from Flash and SRAM 514. Asoftware control loop is created to adjust the frequency of VoltageControlled Crystal Oscillator (“VCXO”) 510. A counter running from VCXO510 clock is sampled each time a packet containing a time stamp from theservice provider's head end. Tuner controller 506 compares thenormalized error in VCXO 510 clock to the headend clock. This way, thelocal clock can be adjusted to be the same frequency as the headendclock.

[0051] Additionally, time stamps T1 can be added to each transportpacket using the recovered system clock from VCXO 510. Time stamp T1 isbased on a sample of the local counter at the moment the packet isreceived at tuner 402.

[0052] The elements of network client 204 are shown in FIG. 6. Dataarrives at the client's time stamp board 602, and time stamp T3 is addedto the data frame at the moment of arrival. The packets are processed byclient controller 608, which is connected to time stamp board 602 viaPCI bus 605. The transport packets are extracted from the networkframes, and are then written to transport formatter board 604. Theoutput of transport formatter 604 is a serial transport stream that maybe used by decoder 606. The output of decoder 606 is connected to atelevision or other display device. FIG. 8 shows the elements of decoder606.

[0053] Client controller 608 is responsible for executing a clockrecovery algorithm. The data frame departure times T2 from server 202are compared to the arrival times T3 at client 204. In this manner,client controller 608 can determine whether decoder VCXO 812 is fasteror slower than server VCXO 510. Client controller 608 sends commands todecoder controller 810 to speed up or slow down decoder VCXO 812 througha low speed serial (RS-232) connection.

[0054] The time stamp board of the client device is similar to the timestamp board of the server device except that the recovered clock sourcein the client device is derived from the clock of decoder 606 ratherthan VCXO 510 of PCI DBS tuner 402.

[0055] The elements of transport formatter 604 are shown in FIG. 7.Transport formatter 604 is connected to client controller 608 via PCIbus 702. A PCI bus interface converts the PCI bus to a standard localbus, which is connected to transport formatter controller 704. Transportformatter controller 704 outputs a serial transport stream at TTL logiclevels. High speed serial converter 706 circuit converts those signalsto low voltage differential signals, which are passed to decoder 606.

[0056] Transport formatter controller 704 has two modes of operation.The first is flow control mode in which transport packets are forwardedto decoder 606 according to the optional time stamps added by tunercontroller 506 of PCI DBS tuner 402. In this manner, the relativetransport packet departure times from transport formatter 604 match thetransport packet arrival times at tuner controller 506. This has theeffect of making the packet timing at the input of decoder 606 appear tobe connected directly to tuner 502 and demodulator 504 of PCI DBS tuner402.

[0057] The second mode of operation allows the data to flow immediatelyfrom transport formatter controller 704 to decoder 606. In this mode,decoder 606 is required to buffer the data internally. This requiresdecoder 606 to contain more memory than the first mode.

[0058] Data arrives from transport formatter 604 into high speed serialinterface 802 of decoder 606. Transport processor 804 sorts the incomingtransport packets and puts them into the correct buffer (video, audio,program guide, other data, etc.). The video and audio data aredecompressed in the video/audio decoder 806. After that, decompresseddigital data is converted to analog NTSC signals via NTSC encoder/audioDAC 808.

[0059] The time stamping board used in implementing the present timestamping method is now further described. Although, described withreference to the time stamping board associated with server 202, asnoted above, the time stamping board associated with client 204 issimilar. Time stamping board 404 is a PCI Ethernet NIC that can supportboth 10 Mb/s and 100 Mb/s data rates. It is capable of resetting the UDPcheck sum and placing 32-bit time stamps in the data frames, as well asrecalculating the CRC for the designated data frames. The externalinterfaces allow board 404 to be integrated into PC PCI or embedded PCIarchitectures. An external clock interface is provided to generate timestamp values.

[0060]FIG. 9 illustrates a block diagram of time stamping board 404. Thetime stamping board comprises an input jack 904, for example RJ45,coupled to Ethernet network 902. Input jack 904 is coupled to 10/100Base-TX Phy transformer 906. Transformer 906 is coupled to physicallayer device 908, which is a full feature physical layer device withintegrated PMD sublayers to support both 10BASE-T and 100BASE-X Ethernetprotocols. Physical layer device 908 is coupled to bus buffer 912, whichtranslates the voltage levels between physical layer device 908 and timestamp controller 916. Bus buffer 912 is a low voltage CMOS octal busbuffer. It is ideal for low power and high-speed 3.3V applications andcan be interfaced to 5V-signal environment for both inputs and outputs.Bus buffer 912 is coupled to time stamp controller 916, which controlsand performs much of the time stamping functions, including, resettingthe UDP check sum, placing the time stamps and recalculating the new CRCfor the valid data frames in both the receive and transmit directions.

[0061] Time stamp controller 916 is coupled to configuration device 918,which stores and loads the program to operate time stamp controller 916.Time stamp controller 916 is also coupled to Ethernet MAC unit 914,which is a LAN controller for both 10 Mb/s and 100 Mb/s data rates.Ethernet MAC 914 provides a direct interface to the peripheral componentinterconnect (PCI) local bus or the CardBus.

[0062] Time Stamp controller 916 provides the MII interfaces to the PHYand the MAC. As shown in FIG. 10, controller 916 consists of receiverunit 1002 and transmitter unit 1004. The two units are implementedseparately, but share the same external system clock and the resetsignal.

[0063] As shown in FIG. 11, receiver unit 1002 comprises receivercontroller 1102, time stamp generator 1114, shift register 1112, verifyCRC module 1110, calculate new CRC module 1106, 3:1 MUX 1108 and 4:1 MUX1104. Receiver controller 1102 detects the status of data stream toenable the 3:1 MUX and the 4:1 MUX for appropriate out put data (receivedata, reset UDP check sum, time stamp, new CRC).

[0064] Calculate new CRC module 1106 calculates the CRC check sum forthe modified data stream (Ethernet packet which has time stamp and resetUDP check sum), this new CRC will be placed into the modified datastream before it arrives at the MAC. The difference of receiver unit1002 to transmitter unit 1004 is that receiver unit 1002 included verifyCRC module 1110. It is necessary to verify the CRC on packets that arereceived, due to the fact that this data may have been corrupted on themedium. If the CRC is not correct, this indicates that the data hasindeed become corrupted. Instead of adding a new, correct CRC to thedata, the data is allowed to pass through to the MAC with an incorrectCRC.

[0065] Controller 1102 synchronizes and controls the operations of allmodules and components. Two clocks are used: a receive clock and anexternal system clock. The time stamp is generated by the external clockand latched into the receive clock domain at the start of every packet.Data is received from the PHY and the appropriate data (receive data,reset UDP check sum, time stamp, new CRC) is transmitted to the MAC inaccordance with IEEE 802.3.

[0066] When the data is received, the time stamp T3 is placed in theappropriate area and a new CRC is calculated and replaces the old CRCvalue in the MAC layer. Again, a significant aspect of the presentinvention is that the time stamps and the CRC are generated and placedin the data frames at the physical layer as the data frame is receivedfrom the network. As such, the time stamps and the CRC, which reflectthe actual time the data frames are received from the network, arequickly and efficiently placed in the data frames as they move to theMAC layer. If at any point of the packet interrogation it is determinedthat the data frame is not a valid time stamp frame or there are errorswhile receiving, the data frame is allowed to pass through with noalterations to the data.

[0067] As shown in FIG. 12, transmitter unit 1202 comprises transmittercontroller 1202, time stamp generator 1210, shift register 1208,calculate new CRC module 1206, 3:1 MUX 1212 and 4:1 MUX 1204.Transmitter controller 1202 controls the operations of all modules andcomponents for each appropriate process. Two clocks are used: a transmitclock and an external system clock. The time stamps are generated by theexternal clock and latched into the receive clock domain at the start ofevery packet. Here again, the time stamps are generated and placed intothe data frames at the physical layer.

[0068] While this invention has been described as having a preferreddesign, the present invention can be further modified within the spiritand scope of this disclosure. For example, the time stamping featuresmay be implemented in other asynchronous networks, including, but notlimited to, HPNA, PLC, and certain wireless networks, for example IEEE802.11b. This application is therefore intended to cover any variations,uses, or adaptations of the invention using its general principles.Further, this application is intended to cover such departures from thepresent disclosure as come within known or customary practice in the artto which this invention pertains and which fall within the limits of theappended claims.

1. A server apparatus for receiving packetized multi-media data andtransmitting the packetized multi-media data over an asynchronousnetwork, the apparatus comprising: an input for receiving packetizedmulti-media data from a signal source, the packetized multi-media dataincluding synchronizing information; a clock; a controller, coupled tothe input and the clock, for synchronizing the clock to a clockassociated with the signal source in response to the synchronizinginformation, the controller generating data frames having the packetizedmulti-media data included therein; an output, coupled to theasynchronous network, for transmitting the data frames to a clientdevice; a time stamping device, coupled to the controller, the clock andthe output, for placing a synchronizing time stamp in the each dataframe, the synchronizing time stamp being indicative of the time therespective data frame is placed onto the asynchronous network, whereby aclient device synchronizes a clock associated with the client devicewith the clock associated with the server apparatus in response to thesynchronizing time stamp.
 2. The server apparatus according to claim 1,wherein the controller generates data flow time stamps in response tothe receipt of the packetized multi-media data, each data flow timestamp being indicative of a time a respective multi-media data packet isreceived at the input, the data frame including the packetizedmulti-media and associated data flow time stamps, wherein the clientdevice controls the data flow rate in the client device to correspond toa rate that the packetized multi-media data is received at the input inresponse to the data flow time stamp.
 3. The server apparatus accordingto claim 2, wherein the data frame comprises a data frame header, timestamp data portion for accepting synchronizing time stamps, and a dataportion for accepting packetized multi-media data and theircorresponding data flow time stamps.
 4. The server apparatus accordingto claim 3, wherein the time stamp data portion includes a first timestamp data portion for accepting the synchronizing time stamp and asecond time stamp data portion for accepting a synchronizing time stampadded by the client device.
 5. The server apparatus according to claim2, wherein the asynchronous network is an Ethernet network.
 6. Theserver apparatus according to claim 2, wherein the asynchronous networkis an HPNA network.
 7. The server apparatus according to claim 2,wherein the asynchronous network is a PLC network.
 8. The serverapparatus according to claim 2, wherein the asynchronous network is awireless network.
 9. A method for transmitting packetized multi-mediadata over an asynchronous network, the method comprising: receiving thepacketized multi-media data from a signal source, the packetizedmulti-media data having synchronizing information; synchronizing aserver clock to a clock associated with the signal source in response tothe synchronizing information; generating data frames having thepacketized multi-media data included therein; placing the data frames onthe asynchronous network to transmit the data frames to a client device,wherein a synchronizing time stamp is generated and placed in each dataframe, each synchronizing time stamp being indicative of the time therespective data frame is place in the asynchronous network, wherein theclient device synchronizes a clock associated with the client device tothe server clock in response to the synchronizing time stamp.
 10. Themethod according to claim 9, further comprising the steps of generatingdata flow time stamps upon receipt of the packetized multi-media data,each data flow time stamp being indicative of a time a correspondingmulti-media data packet is received, and the step of generating dataframes includes generating data frames having the packetized multi-mediadata and the data flow time stamps included therein, whereby the clientdevice controls the data flow rate in the client device to correspond tothe rate the packetized multi-media data is received in response to thedata flow time stamps.
 11. An apparatus for receiving and processingpacketized multi-media data over an asynchronous network, the packetizedmulti-media data comprising data frames having synchronizing time stampsindicative of the time respective data frames are placed on theasynchronous network, the apparatus comprising; an input, coupled to theasynchronous network, for receiving the data frames transmitted by aserver device; a time stamp device, coupled to the input, for generatinga second synchronizing time stamp indicative of the time the data frameis received at the input; a clock; a controller, coupled to the clockand the time stamp device, for synchronizing the clock to a clockassociated with the server device in response to the synchronizing timestamps and the second synchronizing time stamps.
 12. The apparatusaccording to claim 11, wherein the data frames further include data flowtime stamps associated with the packetized multi-media data, the dataflow time stamps being indicative of the time each multi-media datapacket is received by the server, and further comprising a buffer forstoring the packetized multi-media data, and a decoder, wherein thecontroller controls the rate that the packetized multi-media data istransferred to the decoder to correspond to the rate that the packetizedmulti-media data is received at the server in response to the data flowtime stamps.
 13. The apparatus according to claim 12, wherein theasynchronous network is an Ethernet network.
 14. The apparatus accordingto claim 12, wherein the asynchronous network is an HPNA network. 15.The apparatus according to claim 12, wherein the asynchronous network isa PLC network.
 16. The apparatus according to claim 12, wherein theasynchronous network is a wireless network.
 17. A method for controllinga client device in response to the receipt of data frames received overan asynchronous network, each data frames including packetizedmulti-media data and a synchronizing time stamp indicative of the timethe data frame is placed on the asynchronous network, the methodcomprising; receiving the data frames transmitted by a server device;generating second time stamps upon receipt of the data frames, eachsecond time stamp being indicative of the time a respective data frameis received over the asynchronous network; and synchronizing a clock inthe client device in response to the synchronizing time stamps and thesecond synchronizing time stamps.
 18. The method according to claim 17,wherein the data frames include packetized multi-media data and dataflow time stamps, each data flow time stamp being is indicative of atime a corresponding multi-media data packet is received by the serverdevice, further comprising the step of: controlling the rate at whichthe packetized multi-media data is transferred from a buffer to adecoder to correspond to the rate at which the packetized multi-mediadata is received at the server device in response to the data flow timestamps.